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(57) Abstract: Ths 
invention provides a method 
and system for the prevention 
of credit card fraud utilizing a 
communication networc A credit 
cardholder, a Unique Identification 
Device (UID), a merchtint, a credit 
card, issuer and the generation of 
an approval code coiistimte the 
main conqnnents of the method 
and system. The method and 
system can be applied to both 
tt^tional credit card transactions 
and "card not present" credit card 
transactions. The inv6:ntion does 
not require changes tci be made 
to current authorization systems. 
It compliments current systems 
by providing a private channel of 
communication between the credit 



card issuer and the cardholder that is independent of the usual channel used to conduct a transaction. 
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METHOD AND S YSTiM FOR PREVENTING CREDIT CARD FRAUD 

TliB piesent invention relates to a method and system for the prevention of 
credit card fraud through the use of a communication network. 



Credit Cards and their use as payment instruments for the purchase of goods 
and services are widely acc^ted Tliey are used globally through an established 
iiLfrastructure, which eflSciently and conveniently allows payments to be made in 
most areas of the v\rorld. A credit card is usually issued to an individual or a company 
by a financial institution or by a credible merchant with established ties to a bank. A 
credit card holder may present it as a payment to a merchant; the card bearer must 
reimburse the credit card company the amount of the sale later. 

The most popular method of payment in e-commerce is the credit card. The 
purchaser browses the virtual, stores or merchants and selects the items of interest by 
placing them in a shopping cart. When a decision is made to purchase the items 
selected, the customer is directed to the checkout. During the checkout phase, 
customer is requested to enter credit card data and otiier personal infonnation. Upon 
conq>letion of tbese steps, the merchant's virtual store processes the data and sends it 
to a credit card processor, and waits for authorization; similar to traditional card 
swipe (PCS) methods. Once the credit card processor has given the authorization, the 
merchant accepts the order and deUvers the ordered item to the pxirchaser. At this 
stage, the amount of the purchase made awaits to be deducted from the credit card 
holder's account These types of credit card transactions are very similar in nature to 
mail order/phone order (MOTO) transactions. These transactions along with E- 
commerce transactions are categorized by credit card companies as "card not present'' 
transactions. They are regarded as more risky. The rates charged by the merchant 
account providers for credit card transactions in which the actual credit card is not 
present are generally higher than card swipe rates charged in physical ^'card present" 
transactions. This is due to the higher chance of fraud or nonpayment in the ''card not 
present" transactions. 

Unfortunately, merchants and the credit card companies alike are suffering 
from the credit card &aud. Merchants are responsible for chargebacks and credit card 
companies face the risk of a reduction in the number of merchants who are willing to 
accept this type of transaction. In addition, many consumers are reluctant to shop 
online, fearing fraudulent use of their credit card The rate of this sort of crime is 
increasing and is now at an alsurming level. It is seen as a major obstacle to the growth 
of e-conmierce. 
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Most of fhe credit card infoimation used for the fraudulent online purchases 
apparently is obtained in the old-feshioned way: stolen from mailboxes or "swiped" 
through a card reader by accomplices working in restaurants or stores. This stolen 
credit card information is then transmitted to the thief or thieves overseas, who begin 
S their electronic assault on Internet merchants by charging as much merchandise as 
they can in as short a time as possible. In some cases, they will attempt to ship the 
goods directly to fhe country fhey are operating out oj^ wiiere the credit card address- 
verification syistem can't be used because of stringent privacy laws. In other cases, 
since many Internet sellers are now wary of shipping expensive merchandise 

10 overseas, they will enlist accomplices in the Merchant's home countiy who set up 
"drop sites" in vacant homes or rent living quarters under felse names. By fhe time 
the 6-merchant realizes the purchase was made using stolen credit cards, fhe goods 
and the thieves are gone. These days, a credit card number is a valuable commodity to 
thieves. Thieves do not need fhe physical credit card to use somebody's credit card 

IS number, particularly in this era of Ihtemet and catalog shopping; fhe same applies to 
debit cards. A thief armed with a debit card number can go on a shopping spree, 
financed by the cardholder's checking account. Tech-sawy criminals are devising 
new ways to get their hands on card information. They've figured out that card firaud 
beats holding up someone at guapoint. Instead, they're hacking into Ihtemet databases 

20 filled with customer card data and copying account details encoded on a card's 
magnetic stripe. It appears as if credit card firaud is the bank robbery of the fixture. 

Current solutions varj^ Currently, none of fhe solutions completely eliminate 
fiaud. But designing Web sites that require several pieces of information about fhe 
card and fhe potential buyer helps a lot. Those items can tiien be run through 
25 screening software that loolcs for anomalies and red flags, generating a firaud risk 
score. Most of the current approaches focus on huge customer databases that track 
and monitor customer activity to understand behavior patterns of shoppers. Based on 
the collected data and its processing they aim to screen out shopping activity which 
does not match past behavior. 

30 Combating fiaud luis always been a cost of doing business, long before e- 

commerce came along. But another element unique to Internet merchants is title cost 
of losing valuable business as a result of fiaud protection efforts. Antifraud systems 
use algorithms to detect risk, and the systems will reject an order if it falls within a 
designated realm. 

35 Small merchants can afford to phone each customer whose order is deemed 

too risky. But retailers that deploy such systems on a large scale are forced to let 
orders &11 by the wayside, meaning fhey could be losing valuable customers. Some 
merchants are declining large percentage of tiheir orders to minimize fraud, which 
amomts to significant amount of business. 

40 The Credit Card companies have been active in implementing methods to 

prevent credit card fiaud. One of these methods is the CW2/CVC2; a three-digit 
security code tiiat is printed on the back of cards. The mmiber appears in reverse italic 
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at the top of the signature panel at the end (see sample). This program helps validate 
that a genmne card is being used during a transaction. All MasterCard cards, both 
credit and debit, were required to contain CVC2 by January 1, 1997; all Visa cards 
must contain CW2 by January 1, 2001. Card-not-present merchants are being 
5 directed to ask cardholders for CW2/CVC2 vAi&n cardholders place orders. 
Merchants ask the cardholder to read this code from the card. The merchant then asks 
fi>r CW2/CVC2 verification during tiie authorization process. The issuer (or 
processor) validates the CW2/CVC2 and relays the decline/approve results during 
the authorization process. Merchants, by using the CW2/CVC2 results along with 

10 the Address Verification Service (AVS) and authorization responses, can thm make 
more informed decisions about whether to accept transactions, hi addition, merchants 
using CW2/CVC2 can expoct to reduce their chargebacks by as much as 26 percmt. 
Previously the three-digit CW2 or CVC2 number followed the 16-digit account 
number printed on the cards signature panel. The 16-digit account number is now 

15 truncated to four digits on the signature panel. Beginning March 31, 2000, cards 
issued by Equifiix will show the last four digits of the account number followed by 
the three-digit CW2 or CVC2 number on the card signature panel. This change 
makes it easier for cardholders to sign their cards. It also makes it easier for 
merchants to compare the signature on the card to the one on the sales draft; no 

20 longer will those 19 digits (16 + 3) get in the way of verifying a signature! 



The object of the present invention is to provide a method and system for the 
prevention of credit card fi:aud through the use of a communication network. 

25 Figure l.a. is a general working diagram of single code generation 

implementation in a legitimate transaction. 

Figure l.b. is a general working diagram of single code generation 
implementation in an attempted fraudulent use 

Figure I.e. is system flowchart of single code generation implementation. 
30 Figure 2.a. is a general working diagram of shopper check-code generation 

implementation in a le^timate transaction. 

Figure 2.b. is a general working diagram of shopper check-code generation 
implementation in an attempted fraudulent use 

Figure 2.c. is system flowchart of shopper check-code generation 
35 implementation. 

Figure 3. a. is a general working diagram of merchant check-code generation 
implementation in a legitimate transaction. 

Figure 3.b. is a general working diagram of merchant check-code generation 
implementation in an attempted fraudulent use 
40 Figure 3.c. is S3rstem flowchart of merchant check-code generation 

implementation. 

Figure 4. is a diagram of information requested by the merchant to process 
and validate the credit card. 
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Figure 5. is a diagram that illustrates the method by vAiich approval codes 
are generated 

Figure 6 is a diagram of a look up server. 

5 ITie present invention provides a method and system for the prevention of 

credit card firaud utilizing a communication network. A credit cardholder (shopper), a 
Unique IdentLBcation Device (UID), a merchant, a credit card issuer and the 
generation of an approval code constitute the main components of the melbod and 
system, 

10 

The method and system can be applied to both traditional credit card 
transactions ("'card present-POS) and "card not present" credit card transactions 
(VPOS- Le. internet purchases, MOTO — i.e.: mail or telephone orders). The 
invention does not require changes to be made to current authorization systems. It 
IS compliments current systems by providing a private channel of communication 
between the credit card issuer and the cardholder that is independent of Ihe usual 
channel used to conduct a transaction. 

For the purposes of this desoiption we will outline 4 stages in the 
20 completion of a transaction using a credit or debit card. 

Validation : information necessary for llie processing of the credit card is 
checked to be valid, i.e. of the correct type and length. Credit card numbers may only 
be valid if they are 16 digits long. 

25 Authorization: when a credit card issuer receives a request to process a credit 

card certain checks are made. The credit card niunber must match an existing 
account The account must be active and sufELcient funds must be available. This 
process will be referred to as authorization. When a transaction is authorized funds 
are allocated for transfer to the merchant's accoimt. 

30 Vertfication: the invention offers the ability to verify the identity of a 

shopper attempting to use a credit card to make a purchase. The invention can 
determine whether or not the shopper is the cardholder for a specific account This 
process is referred to as verifi cation. 

A pproval: when a transaction has been validated, authorized, and verified it 

35 is referred to as an approved transactioru 

The cardholder is an individual or a company, having an active credit card 
account with which transactions can be processed. Also used to refer to the actual 
owner of an identification de^idce supplied by any orgaxiization used for verifying the 
40 relationship between the organization and the individual. 

The shopper is any individual, company, government organization or private 
organization that initiates an action \^ch requires approval of a purchasing process 
using credit card. The shopper may or may not be the actual cardholder 
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himsel£liersel£ If the shopper is not ifae cardholder, he/she is attempting to use the 
credit card fiaudulently. 

The credit card issu^ is a public or private organization that issues credit 
5 cards or debit cards to be used for &e purchase of merchandise or services. Credit 
card issuer then bills the customer and is responsible for maintaining the cardholder's 
personal and card related data. The term may also be used to refer to an agency acting 
on behalf of the issuing body. 

10 Unique Idetitification Device (UID) refers to a device, specific to the 

cardholder, that provides communication or sharing of information between parties. 
Such a device has a privacy property that is known to the device o^^er. Examples of 
UID's include GSM phones, e-mail accounts, pagers, personal computers, Intemet 
enabled PDA*s (Personal Digital Assistants) and similar devices. UID's may have the 

15 capacity to store and execute programs. A UID may be capable of only unidirectional 
communication. A pager is wi example of such a UID. It can receive a message but 
cannot respond to it Other UID*s allow for interactive bi-directional communication. 
A telephone (wireline) or mobile phone (wireless) may receive and send voice and 
text messages such as those used in SMS (Short Message Service). An email account 

20 may send and receive messages. 

An approval code is generated and exchanged between the credit card issuer, 
the shopper (cardholder), and/or the merchant for identification, verification and 
purchase approval. An aiq>roval code is a series of alphanumeric characters and is 
25 only accessible by the credit card issuer, the cardholder and cardholder-aufhorized 
third parties via the cardholder's UID. By exchanging the approval code among the 
involved parties, the invention verifies the identity of the cardholder and prevents 
unauthorized use. 

30 The method and system and its in:^>lementation variatioxis are explained as 

follows; 

Single code generation impliementation. 

An approval code is generated by the credit card issuer and is either sent 

35 directiy to the cardholder's UID or made available to the cardholder throu^ a secure 
channel of distribution such as a web site. The cardholder enters the code when the 
merchant's system prompts for it When the code has been entered in the merchant's 
system, it is sent to the credit card issuer for comparison. The credit card issuer 
carries out comparison of the ^proval codes. Code generation does not take place on 

40 the merchant's system. This alternative is ^own ni detail in Figs 1 .a 1 .c. 

Shopper check-code generation implementation. 

Code generation takes place both on the credit card issuer's system and on 
tiie cardholder's UID, which, in this alternative, must be capable of storing and 
45 executing a program. The code generated by the UID is requested by the merchant 
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system as part of the infoiinatLon necessary to initiate a transaction. This approval 
code is then sent to the crediit card issuer for comparison of the codes. This alternative 
is shown in detail in Figs 2.a-2.c. 

5 

Merchant check-code generation implementation. 

Code generation takes place on both the credit card issuer's system and the 
merchant's system. The approval code gmerated by the credit card issuer is sent to 
10 the cardholder's UID. The merchant's system is responsible for conqparison of tiie 
codes. This alternative is shown in detail in Figs 3.a-3.c. 

Single code generation implementation in detail. 

Accompemying figures 
15 1 -a Flow of information in a legitimate transaction 

l.b Flow of information m an attempted fraudulent use 
1 .c System Flowchart 

In this scenario, the credit card issuer does not verify flie identity of the 
20 shopper unless the merchant site sends an approval code. An approval code is 
generated by the credit card issuer's system. This code may either be sent directiy to 
the credit cardholder's UID or made available on demand to the credit card holder. 
The cardholder then provides the merchant with the approval code. In the case where 
the shopper is the actual cardholder they will be able to provide the correct code but if 
25 the shopper is not the cardholder thm they will not be able to provide the approval 
code. 

The merchant system sends the approval code received fiom the shopper to 
the credit card issuer. The credit card issuer receives and compares the two approval 
codes (Credit card issuer generated approval code and merchant sent approval code). 
30 If the codes match each other then the credit card issuer verifies the identity of the 
shopper> approves the order and notifies the merchant. 

The scenarios below describe the processes involved in a legitimate transaction and in 
a case of attempted fimidulent use. The exanq>les use e-«onunerc6 as a contex:t but the 
35 same processes would i^ply m any transaction. 

The actual cardholder initiates the credit card transaction and the 
credit card issuer is method-enabled. The merchant's web site has been modified 
to handle the method and system (Fig. l.a): 

40 

Step 1- During a typical on-line purchase; the credit card holder (shopper) 
completes the selection of products or services over the e-conunerce site. The shopper 
then enters his/her credit card data along with other personal information such as 
address, etc. to merchant's site. 
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Step 2 - The shopper's credit card data is seat for authorization by the credit 
cai'd issuer. 

Step 3 - The credit card issuer checks the incoming data sent by the 
medTchant The credit card is Ihen authorized. Hie transaction itself is not yet 
5 cojXLpleted. An approval code is generated by the credit card issuer's system. This 
co( je is either sent to the UH) of the cardholder ox made available to them on demand. 
The credit card issuer may have obtained the cardholder's UID access data 
previously. 

Step 4- The merchzint asks for an approval code field to be filled in by the 
1 0 shopper. To complete the transaction the shopper enters the approval code. 

Step 5 - The merchant site sends the approval code supplied by the shopper to 
the credit card issuer fox comparison. 

Step 6- The credit caxd issuer checks the incoming code and verifies the 
id($ntity of flie shopper. The credit card issuer then sends the approval confirmation to 
IS the merchant. 

The credit card transaction is initiated by an unauthorized shopper 
(firaudulent card use) and the credit card issuer is method enabled. The 
merchant's web site has been modified to handle the method and system (Fig. 

20 

Ste p 1 " During a typical on-line purchase die shopper completes the 
selection of products ox services over the e-commerce site. The shopper then enters 
his/her credit card data along with other personal information such as address, etc. to 
25 die merchant's site. 

Step 2 - The shopper's credit card data is sent for authorization by the credit 
card issuer. 

Step 3 - The credit card issuer checks the incoming data sent by the 
merchant. The credit card is then authorized for use. The transaction itself is not yet 

30 completed. An approval code is generated by the credit card issuer's system. litis 
ccide is either sent to the UID of the cardholder or made available to fliem on demand. 
Hie credit card issuer may have obtained the cardholder's UID access data 
previously. If the approval code has been sent to the cardholder's UID then the 
csxdholder is aware that a third party is attenq>ting to carry out a transaction using 

35 their credit card and can respond by contacting the credit card issuer. This contact 
may be fiicilitated by a 'reply' functionality included in the approval code messages 
that are sent to the cardholder's UID. When the cardholder receives the approval code 
message they can reply to it, usually using a built in function of their UID. The 
oiiginator of the message would then receive tiie reply and could act on it by 

40 triggering an alarm message or procedure. The ultimate aim of the 'reply' 
flmctionality is to automate the process of informing a credit card issuer that 
attempted firaudulent use of a card is taking place. 

Step 4 - The merchant asks for an ^jproval code field to be filled in by the 
shopper. The shopper, who is not the cardholder, has not received the approval code 

45 and cannot sxspply it 
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Steps- Hie merchant site sends eithei no apinroval code or an incorrect code 
supplied by the shopper to the credit card issuer for comparison. 

Step 6 - The credit card issuer checks the incoming code and cannot verify 
the idraitity of the shopper. Credit card issuer then informs the merchant that approval 
5 for the transaction cannot be given. 

Flowchart, refer to Fig. l.c; 

Merchant: 

10 

In step 4100 and 4101, the information entered by Ihe shopper is validated 
In step 4102, the validated customer data by the merchant site is sent to the credit 
card processor for data processing and routing for credit card authorization. The 
information is sent to credit card issuer by the credit card processor or similar 
1 S organizations in the following step 4300. 

In step 4103, the result of the authorization request is received from the credit card 
issuer. 

In step 4104, the authorization message fix>m the credit card issuer is evaluated. If 
authorization is obtained then step 4106 is processed, otherwise step 4110 is 
20 processed. 

In step 4106, the merchant site receives the approval code entered by the shopper. 
Jn step 4109, the sliopper data along with the approval code entered by Ihe shopper is 
communicated to the credit card issuer for iQ)proval. At this moment, the order has 
not been approved by the cre^dit card issuer. 
25 In step 41 10, the merchant system informs the shopper that the transaction has either 
not been authorized or not been approved. 

In step 4111, the merchant site gets the final purchase approval fi:om the credit card 
issuer. 

In step 4112, the cjredit card issuer's response is evaluated. If the credit card issuer 
30 has approved the order then step 4113 is performed. Otherwise, the step 4110 is 
processed. 

In step 41 13, the ciredit card issuer has approved the order. The merchant mforms the 
shopper about the purchase order approval. 

35 The Shopper: 

hi step 4200, the sihopper enters all the information requested by the merchant's site. 
Figure 4 shows the ioformatiQn requested by the merchant to process and validate the 
credit card. 

40 In the steps 4201 and 4202 the shopper/cardholder receives Ihe approval code and 
enters it into the merchant site. 

Only the cardholdc^r can obtain the approval code. Shoppers who are not cardholders 
will not receive the correct approval code. 

45 Credit Card Processor: 
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In steps 4300 and 4303, the credit c^ard processor receives the data in a predetermined 
format, processes it and Hxen routes it to the destination for further processing and 
authorization. At this stage, the merchant suj^Iied data is handled by the credit card 
S processor and communicated to the credit card issuer. The credit card processor and 
other intermediary organizations use different versions of VPOS software and 
systems to process credit card auth>3rization requests. The procedures are similar but 
may display some variations depending on the credit card association and the 
different countries involved. 

10 

The Credit Card Issuer: 

In step 4401, the credit card, issuer receives the credit card authorization request and 
processes it using the credit card customer data it possesses according to the 
IS procedures and rules established by the credit card associations and the countries 
involved in the particular traosaction. 

In step 4402, the credit card issuer receives the data firom the merchant for first 
authorization. If the credit card is not authorized then this information is passed to the 
merchant (step 4301). If the credit card is authorized thra step 4403 is processed. 

20 In step 4403, authorization informafion is sent to the merchant by step 4301, 

In step 4404, the credit card issuer gCT.eratBs an approval code that is sent to the 
cardholder's UID. The UID access information is in the credit card issuer's database 
and it has been obtained by the bank during initial card issuing process. 
In step 4405, The shopper data along with tiie approval code entered by the shopper is 

25 communicated to the credit card issuer for final approval. 

hi step 4406, the approval code received firom the merchant entered by the shopper 
and the one generated by the credit card issuer are compared, If the epptGval codes 
match then the identity of the shopper is verified and step 4407 is performed. If they 
do not match then step 4408 is processed. 

30 In step 4407, the transaction is approved. Merchant is notified via step 4303. 

In step 4408, the credit card issuer does not approve the transaction and sends this 
information to the merchant visL step 4303. 

35 POS processing for single code generation implementation. 

Hie invention applies to traditional credit card purchases as vrell as on-line, 
mail order or telephone "card not present" transactions. During a traditional credit 
card purchase, merchants use a physical POS device to swipe the credit card. Most 

40 current POS devices are equipped with a keypad. In order to apply the invention to 
regular POS processing, all the merchant system is required to have is a shopper 
interface that accepts approval codes (sent by the credit card issuer to shopper's UID) 
and communicates them to the credit card issuer. This interface may use the regular 
POS device or merchant supplied secure data entry device. If the correct approval 

45 code cannot be sent to the credit card issuer in a predefined period of time then the 
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credit card issu^ cancels the approval process and the entire process needs to be 
started from the begiiming. The merchant swipes th(5 card throng the POS device. 
The credit card issuer authorizes the transaction but does not approve the order at this 
time. An approval code is generated by the credit caid issuer and sent to the UK) of 
5 the cardholder. The cardholder is standing by the POS device and expecting to 
receive an approval code via his/her UID. The message comes to the UID of the 
cardholder. The cardholder enters the approval code by using merchant provided 
interfiice (i.e., POS device's own buttons). The approval code is sent to the credit card 
issuer. Ihe ci^t card issuer compares the codes to verify the identity of tiie shopper 
10 and either approves the order or not. This logic makes the sjrstem extremely secure 
since each code generated is unique and for one-time use only. 

Shopper check-code generation implementation. 

Accompanying figures 
1 5 2.a Flow of information in a legitimate transaction 

2.b Flow of infomtiation in an attempted fraudulent use 
2.C System flowchart 

In diis second scenario, the cardholder's UID is a programmable device and is 
20 capable of generating an approval code. Both the credit card issuer and the 
cardholder's UID generate approval codes. In order for these codes to match both 
code generation processes need access to the code generation key. Figure 5 illustrates 
the method by which approval codes are generated with or without the use of code 
generation keys. The code generation key is an alphi'inumeric code used to verify the 
25 identity of an individual attempting to use a credit C2u*d, debit card, or other account 
The code generation key is assigned by the credit card issuer or chosen by the 
cardholder and accessible only by the credit card issuer and the cardholder. 

Another fector used in the generation of an approval code is a time/date 
30 value. The use of a time/date value ensures that the value generated as an approval 
code will be time sensitive. Approval codes will, tiierefore, have a limited lifespan. 
The length of this lifespan can be varied to meist the demands of the specific 
implementation. In one implementation, for example, the lifespan of the approval 
code could be set to IS minutes, ensuring that a code generated at 9:00am would 
35 ceasetobe valid at 9:16am. 

In order to avoid localization issues and ensure fliat approval codes generated in 
different locations match, all systems involved in a transaction should base their 
generation of approval codes on an agreed .time-zone and make an adjustment for 
40 their local time zone before carrying out a comparison of approval code values. In a 
transaction for a shopper in Istanbul (GMT +2), purchasing goods or services from a 
merchant in London, using a card issued by a credit card issuer in New York (GMT - 
5), three dififerent time zones may be involved. An;^ time-based input into approval 
code generation would need to be based on a single time zone. If GMT is the agreed 
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standard then systems in Istanbul would use local time —2 and systems in the USA 
would use local time + 5. 

The scenarios below describe the processes involved in a legitimate 
S transaction and in a case of attempted fraudulent use. The examples use e-commerce 
as a context but the same processes would apply in any transaction. 

The actual cardholder initiates the credit card transaiction and the 
credit card issuer is method-enabled. The merchant's web site has been modified 
to handle the method and system (Fig. 2.a): 

10 

Stepl - During a typical on-line purchase the credit cardholder (shopper) 
completes the selection of products or services over the e-commerce site. The shopper 
then enters his/her credit card data along with oth^ personal information such as 
address, etc. to the merchant's site. In this step, an ^proval code is specifically 
15 requested by the merchant system. The shopper enters the approval code generated by 
his/her UID. 

Step 2 - The merchant sends the data required for ^proval (including the 
approval code entered by the shopper) to the credit card issuer. 

Step 3 - the cre^t card issuer generates an approval code. This approval code 
20 is compared with the approval code sent by the merchant. If the credit card . 
information is correct and tiie approval codes match then the transaction is approved 
by the credit card issuer and the merchant is notified of the approval. 

The credit card transaction is initiated by an unauthorized shopper 
25 (fraudulent card use) and the credit card issuer is method enabled. The 
merchant's web site has been modified to handle the method and system (Fig. 
2.b): 

Step 1 - During a typical our-line purchase the shopper completes the selection 
30 of products or services over the e-commerce site. The shopper then enters his/her 
credit card data along with other personal information such as address^ etc. to the 
merchant's site. In this st&p an approval code is specifically reijuested by the 
merchant's system. As the Copper is not the actual cardholder, the^ approval code 
generated by the cardholder's UID cannot be accessed by the shopper. The shopper 
35 either does not enter an approval code or enters an incorrect approval c;ode. 
Step 2 - The merchant sends the data to the credit card issuer. 
Step 3 - t he credit canl issuer generates an approval code. This approval code 
is compared with the approval code sent by the merchant The approvEil codes will not 
match, since the actual s^proval code cannot be accessed by the shopper. The credit 
40 card issuer does not approve the transaction request Credit card issuer then sends the 
result of the s^proval request as not approved to the merchant 

Flowchart, refer to Fig. 2.c; 

45 Merchant: 
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In step 5 1 00 and 5 101, the information entered by the shopper is validated. 
In stqp 5102, the validated ciistomer data is sent by the merchant site to the credit 
card processor for data processing and routing for credit card authorization. The 
5 information is sent to the credit card issuer by the credit card processor or similar 
organizations in the following step 5300. This information also contains the approval 
code entered by the shopper. 

In step 5110, the merchant system warns the shopper that the transaction is not 
approved and stops the processing of the purchase request 
10 In step 5111, the merchant site gets the final purchase approval from the credit card 
issuer. 

In step 5112, the credit card issuer's response is evaluated. If the credit card issuer 
has approved the order then the step 5513 is performed Otherwise, the step 5110 is 
processed. 

15 In step 5513, the credit card issuer has approved the order. The merchant informs the 
shopper about the purchase order approval. 

The Shopper: 

20 In step 5200, the shopper enters all the information requested by the merchant's site. 
Figure 4 shows the information requested by the merchant to process and validate the 
credit card. In this step, an approval code is specifically requested by the merchant 
system. 

In step 5203, the shopper is informed that the transaction has not been approved. 
25 In step 5204, the shopper is informed that the transaction has been approved. 

Credit Card Processor: 

• In steps 5300 and 5303, the credit card processor receives the data in a predetermined 
30 format, processes it and then routes it to the destination &r further processing and 
authorization. At Hiis stage, the merchant supplied data is handled by the credit card 
processor and communicated to the credit card issuer. The credit card processor and 
other intermediary organizations use different versions of VPOS software and 
systems to process credit card authorization requests. Ihe procedures are similar but 
35 may display some variation depending on the credit card association and tiie different 
countries involved. 



The Credit Card Issuer: 
40 In step 5401, the credit card issuer receives the credit card i^jproval request and 
processes it using the credit card customer data it possesses according to the 
procedures and rules established by the credit card associations and the countries 
involved in the particular transaction. 

In step 5404, the credit card issuer generates an approval code. 
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In Step 5406, fhe approval code received firom ftie merchant and the one generated by 
the credit card issuer are compared. If the approval codes match, step 5407 is 
performed If not, tiben step 5408 is processed 

Jn step 5407, the transaction is approved Merchant is notified via step 5303. 
5 In step 5408, the credit card issuer does not approve the transaction and sends this 
information to the merchant via step 5303. 

POS processing for shopper check-code generation. 

10 The invention applies to traditional credit card purchases as well as on-line, 

mail order or telephone "cjird not presenf ' transactions. During a traditional credit 
card purchase, merchants use a physical POS device to swipe Ihe credit card Most 
recent POS devices are equipped with a keypad In order to apply the invration to 
regular POS processing, all the merchant system is required to have is a shopper 

15 inter&ce that accepts approval codes (generated hy the shopper's UID) and 
communicates them to the credit card issuer. This inter&ce may use the regular POS 
device or merchant supplied secure data entry device. If the correct ^proval code 
cannot be sent to the credit card issuer in a predefined period of time then the credit 
card issuer cancels the approval process and the entire process needs to be started 

20 from fhe beginning. The merchant swipes the card through the POS device. The credit 
card issuer authorizes the transaction but does not approve the order at this time. An 
approval code is generated by the cardholder's UID. The cardholder enters the _ 
approval code by using merchant provided interface (i.e., POS device's own buttons). 
The approval code is sent to the credit card issuer. The credit card issuer compares 

25 the codes to verify the identity of the shopper and either approves tiie order or not 
This logic makes the system extremely secure since each code generated is unique 
and for one-time use only. 

Merchant check-code generation implementation. 

30 Accompanying figures 

3.a Flow of information in a legitimate transaction 
3.b Flow of information in an attempted firaudulent use 
3 .c System flowchart 

35 In this third scenario, the approval code generation may take place on both 

the merchant and the credit card issuer's system. The comparison of codes must take 
place on the merchant's system. 

When a shopper wishes to make a purchase using a credit card they supply 
40 their credit card data to the merchant system. This information may or may not 
include a code generation key. Ihe merchant system will s&at the cre^ card related 
information to the credit card issuer for authorization. If a code generation key is 
siq)plied it will be used to generate an approval code. 
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The credit card issuer receives the inforroatioii siqpplied by the merchant and 
eiflier authorizes or declines the transaction request If the request is authorized and 
the card is protected by the invention tiien the credit card issuer generates an approval 
code and sends it to the UDD of the cardholder. 

5 

If the credit card issuer authorizes the transaction and the shopper has 
provided a code generation key then the shoppar will be prompted by the merchant to 
enter the approval code sent to their UID by the credit card issuer. The merchant can 
flien make the comparison between the code it has generated and the code entered by 
10 the shopper. The transaction is either verified and approved or declined 

The table below shows the possible combiaations of processes that characterize a 
credit card transaction based on merchant and credit card issuer's status. 



No 


Invention 
Enabled 


Not Invention 
Enabled 


RESULT 


1 


Merchant 

Credit Card 
Issuer 




The identity of the shopper is verified as 
the authorized user of the credit card. If 
the shopper is attempting to use the card 
fraudulently and does not enter a code 
generation key then the cardholder is 
made aware of this fraudulent use by the 
approval code being sent to their UID. 
If the shopper enters an incorrect code 
generation key then the transaction is 
not approved. 


2 


Credit Card 
Issuer 


Merchant 


The invention will inform the 
cardholder if attempted fraudulent credit 
card use is in progress. Although the 
credit card issuer may authorize the 
transaction the cardholder can inform 
the Issuer as soon as the approval code 
is received by Ifaeir UID. 


3 




Merchant 

Credit Card 
Issuer 


Transaction proceeds using current 
authorization process. 


4 


Merchant 


Credit Card 
Issuer 


Shopper will not provide a code 
generation key. Transaction proceeds 
using current authorization process. 
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The scenarios below describe the processes involved in legitimate 
transactions and in cases of attempted fraudulent use. The examples use e-commerce 
as a context but the same processes would apply in any transaction. 

5 The credit card transaction is initiated by the actual cardholder and the 

credit card issuer is method-enabled (Fig.3.a): 

Stepl - During a typical on-line purchase the credit cardholder (shopper) 
completes the selection of praducts or services over the e-commerce site. The shopper 
10 then enters his/her credit card data along with other personal information such as 
address, etc. to the merchant's site. The merchant specifically requests a code 
generation key from the shopper. The shopper is the cardholder and has access to this 
key. 

Step 2- The merchant sends the data required for authorization to the credit 
IS card issuer. 

Step3 - The credit card issuer authorizes the transaction, allocates funds for 
transfer to tiie merchant's account and generates an approval code which is sent to the 
cardholder's UID. 

Step 4 - Because the shopper has provided a code generation key the 
20 merchant prompts the shopper for an approval code. The shopper enters the approval 
code sent by the credit card issuer to his/her UID. The merchant compares the 
approval codes, verifies the identity of the shopper and approves the transaction. 

The actual cardholder initiates the credit card transaction and the 
25 credit card issuer is not method-enabled (Fig. 3.a): 

Step 1 - During a typical on-line piuchase the credit cardholder (shopper) 
completes the selection of products or services over the e-commerce site. The shopper 
then enters his/her credit card data along with other personal information such as 
30 address, etc. to the merclumt's site. The merchant specifically requests a code 
generation key from the stiopper. The shopper does not have access to a code 
generation key because their credit card issuer has not provided them with one. The 
shopper leaves this field blank. 

Step 2 - The merchant sends the data required for authorizadon to the credit 
3S card issuer. 

Step 3 - T he credit card issuer authorizes the transaction and allocates funds 
for transfer to the merchant 's account. No approval code is generated as the credit 
card issuer is not using the in vention. 

Step 4 - T he merchmt does not prompt the shopper for an approval code as 
40 no code generation key has been provided. The transaction is complete. Ihis 
transaction is xmeffected by the invention. 

The credit card transaction is initiated by an unauthorized shopper 
(fraudulent card use) and the credit card issuer is method-enabled (Fig. 3.b): 
45 (Fig. 3.b) 
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Step 1 - During a typical on-line purchase the shopper (unauthorized^ 
completes the selection of products or sendees over the e-commerce site. The shopper 
then enters the cardholder's credit card data along with other personal infonnation 
such as address, etc. to the merchant's site. The merchant specifically reqpiests a code 
5 generation key from the shopper. The shopper does not have access to the 
cardholder's code generation key. The shopper may enter an incorrect key or leave 
the field blank. 

Step 2 - Hie merchant sends the data required for authorization to the credit 
card issuer. 

10 Step 3. The credit card issuer authorizes the transactioti, allocates funds for 

transfer to the merchant's account and generates an approval code, which is sent to 
the cardholder's UID. 

Step 4. If the shopper has provided a code generation key then the merchant 
site will prompt them for an approval code. This code is only available through the 

IS cardholder's UID and the shopper will not be able to obtain the code. In this case the 
merchant will not complete the transaction. If the shopper has not provided a code 
generation key then the merchant site will not prompt for an approval code and will 
complete the transaction. In either case the cardholder is made aware that a third party 
is attempting to carry out a transaction using their credit card and can respond by 

20 contacting the credit card issuer. This contact may be facilitated by a *reply* 
functionality included in the approval code messages that are sent to the cardholder's 
UID. When the cardholder receives the approval code message they can reply to it, 
usually using a birilt in function of their UID. The originator of the message would 
then receive the reply and could act on it by triggering an alarm message or 

25 procedure. The ultimate aim of the 'reply' functionality is to automate tiie process of 
informing a credit card issuer that attempted fi:audident use of a card is taking place. 

The credit card transaction is initiated by an unaufhorized shopper 
(fraudulent card use) and the credit card issuer is not method-enabled (Fig. 3.b): 

30 

Step 1 - During a typical on-line purchase the shopper (unauthorized) 
completes the selection of products or services over the e-commerce site. The shopper 
thc»i enters the cardholder's credit card data along with other personal information 
such as address, etc. to merchant's site. The merchant specifically requests a code 
35 generation key firom the shopper. The shopper does not have access to the cardholders 
code generation key. The shopper may enter an incorrect key or leave the field blank. 

Step 2. The merchant sends the data required for authorization to the credit 
card issuer. 

Step 3- The credit card issuer authorizes the transaction and allocates funds 
40 for transfer to the merchant's account. 

Step 4. The merchant site receives the authorization firom the credit card 
issuer. The transaction is conoplete. This transaction is uneffected by the invention. 

Flowchart, refer to Fig. 3.c; 

45 
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The Merchant: 

In step 3100 and 3101, the information entered by the shopper is validated, 
in step 3102, -Qie validated customer data is sent by the merchant site to the credit 
5 card processor for data processing and routing for credit card authorization- The 
information is sent to the credit card issuer by the credit card processor or similar 
organizations in step 3300. 

Ih step 3 103, the authorization result is received from the credit card issuer 
In step 3 104, the authorization resTilt from the credit card issuer is evaluated 

10 In step 3105, if the transaction is not authorized then the merchant site informs the 
shopper about this failure. If the transaction is authorized then step 3107 is processed. 
In step 3107, an evaluation is performed to determine whether the shopper has 
provided a code generation key. If no code generation key has been provided thoa 
step 3112 is performed. Step 3112 represents the normal conclusion of a credit card 

15 transaction without the protection of the invention. If the shopper has provided a code 
generation key then step 3108 is processed 

In step 3108, an approval code is generated using the code generation key provided 
by the shopper. 

In step 3109, the merchant site receives flie approval code entered by the shopper. 

20 In step 3110, the code generated by the merchant site and the code entered by the 
shopper are checked to determine if they match. If the codes are the same then the 
order is accepted and the step 3113 will be processed. If the approval codes do not 
match then the merchant is aware that the identity of the shopper has not been 
verified. The merchant may either accept the order and ship the products, accepting 

25 the risk that the credit card issu^ may revoke the transaction at a lat^ date (NO 1), or 
refrise to accept the order and cancel the transaction by communicating with the credit 
card issuer (NO 2). 

The Shopper: 

30 

In step 3200, the shopper enters all the information requested by the merchant's site. 
Figure 4 shows the information requested by the merchant to process and validate the 
credit card. The shopper is also asked to provide a code generation key. 
In steps 3201, the shopper receives the approval code sent to the cardholders UID by 

35 the credit card issuer. 

In step 3202, the approval code is provided to the merchant site by the shopper. 
The shopper can obtain the approval code only if the shopper is the cardholder. If the 
cardholder receives an approval code for a transaction they have not initiated they are 
made aware that a third party is attempting to carry out a transaction using their credit 

40 card and can respond by contacting the credit card issuer. This contact may be 
fecilitated by a *reply' fimctionality included in the approval code messages that are 
sent to the cardholder's UID. When the cardholder receives the approval code 
message they can reply to rt, usually using a built in frmction of their UID. The 
origLoator of the message would then receive the reply and could act on it by 

45 triggering an alarm message or procedure. The ultimate aim of the ^reply' 
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fimctioiiality is to automate the process of informing a credit card issuer that 
attempted fiaudulent use of a card is taking place. 

Credit Card Processor: 

5 

In steps 3300 and 3301, the credit card processor receives the data in a predetermined 
format, processes it and then routes it to t&e destination for further processing and 
authorization. At this stage, the merchant supplied data is handled by the credit card 
processor and communicated to the credit card issuer. The credit card processor and 
10 other intermediary organizations use difTerent versions of VPOS sofiware and 
systems to process credit card authorization requests. The procedures are similar but 
may display some variations depending on the credit card association and the 
different countries involved. 

15 The Credit Card Issuer: 

In step 3400 and step 3401, the credit card issuer receives the credit card 
authorization request and processes it using the credit card customer data according to 
the procedures and rules established by the credit card associations and the countries 

20 involved in the particular transaction. 

In step 3401, if the credit card is not authorized then this information is passed to the 
merchant via steps 3301. If the credit card issuer authorizes the credit card this 
information is also passed to the merchant following the same steps. 
In step 3402, if the credit card issuer is protected by the invention then step 3403 is 

25 processed and an approval code is sent to the cardholders UID in Step 3301 . 

In step 3403, the credit card issuer generates an approval code. This approval code is 
sent to the cardholder's UID. But in this step the credit card issuer is not sure whether 
the approved purchase is fiaudulent or not even if the card has authorized. 

30 LOOK UP SERVER OPTION 

In the above scenarios the merchant cannot identify whether or not an 
individual credit card is protected by the invention. In order to make the system more 
effective a look xsp server can be added. The role of a look up server is described in 
35 Fig. 6. By including a look up server in the invention configuration, the merchant 
becomes aware whether the credit card subnutted in the purchase request is protected 
by the invention or not 

The look up server maintains receives a query from a merchant containing 
40 the jSrst 'n' digits of a credit card number where 'n' is the number of digits necessary 
to identify the credit card issuer and the type of credit card in use. These digits do not 
represent individual credit csirds. The look up server maintains a list of these partial 
credit card numbers, which is added to whenever a new type of credit card is 
protected using the invention. The look up server can respond to the merchant with a 
45 value indicating that the type of card is either protected by the invention or is not. The 
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merchant then proceeds with knowledge of the credit card's protection status. This 
knowledge allows the merchant to refuse to process transactions from cards protected 
by the invention without the presentation of either 

L A Code Generation Key 
5 H. An Approval Code 

nL Both 

If the shopper does not provide the reqiured information then the merchant 
can halt processmg of the transaction at that point 
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CLAIMS 

1 . A method and systcsm for preventing credit card fraud comprising the steps of: 

5 the credit cardholder provides the merchant vAih the information necessary for 

credit card aiithori2;a(ion; 

the oiedit card issu» receives the credit card specific information obtained by 
the merchant; 

the credit card issuer processes the credit card for authorization ; 
10 if the credit card is authorized then the credit card issuer generates an approval 

code and this approval code is sent to the unique id^itification device (UID) 
of the cardholder using a commuiucation network; 

the credit card iss^uer coimnunicates the authorization decision to the 
merchant; 

IS the merchant prompts the cardholder to supply an approval code; 

the cardholder siq>plies the approval code they have received via Ifaeir unique 
identification device <CUID); 

the merchant sends the approval code presented by the shopper to the credit 
card issuer; 

20 the credit card iss^uer compares the approval code it has generated with the 

approval code sent bj*^ the merchant; 

the credit card issuier approves the credit card transaction only if the approval 
codes match. 

25 2. A method and system for preventing credit card fraud comprising the steps oC 

the credit cardholder isrovides the merchant with the information necessary for 
credit card authorLsation; 

the credit card issuer receives the credit card specific information obtained by 
30 the merchant; 

the credit card issuer processes the credit card for authorization; 

if the credit card is aiithorized then the credit card issuer generates an approval 

code, which is made available to the cardholder in a mutually agreed protected 

environment; 

3S the credit card issuer communicates the authorization decision to the 

merchant; 

the merchant proic^its the cardholder to supply an approval code; 

the cardholder retrieves the approval code from the mutually agreed protected 

environment; 

40 the cardholder supplies the merdbant vnih. the approval code they have 

retrieved; 

the merchant sends the approval code presented by the shopper to the credit 
card issuer; 

the credit card issuer compares the approval code it has generated with the 
45 approval code sent by the merchant; 

20 
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the credit card issuer approves the credit card transaction only if the approval 
codes niatch. 

3. A method and system for preventing credit card fraud comprising the steps of: 

5 

the credit cardholder provides the merchant with the information necessary for 
credit card authorization; 

the cardholder uses their unique identification device (UID) to generate an 
approval code hased on the code generation key associated with their credit 
10 card; where code generation key is im alphanumeric code used to verify the 

identity of the cardholder and it is acc;essible only by the credit card issuer and 
the cardholder; 

the cardholder provides the merchant with this approval code; 

the merchant sends tlie credit card specific information with tiie approval code 
IS to the credit card issuer; 

the credit card issuer receives the information sent by the merchant; 

the credit card issuer processes the credit card for ai]thori2^tion; 

if the credit card is ai^diorized then the credit card issuer generates an approval 

code based on the code generation key associated with the credit card; 
20 the credit card issuer compares the approval code it has generated with the 

approval code sent by the merchant; the credit card issuer approves the credit 

card transaction only if the approval codes match. 



25 



4. A method and system for preventing credit card fiaud comprising the steps of: 



tiie credit cardholder provides tiie merchant vnUi the information necessary for 
credit card authorization; 

the credit cardholder provides the merchant with the code generation key 
associated wifii their credit card; where code generation key is an 
30 alphanumeric code used to verify the identity of the cardholder and it is 

accessible only by the credit card issiier and the cardholder; 
the credit card issuer receives the cn»dit card specific information obtained by 
the merchant; 

the credit card issuer processes the ci'edit card for authorization ; 
35 if the credit cardholder has provided a code generation key and the transaction 

has been authorized by the credit card issuer then the following additional 
steps take place: 

the credit card issuer generates an approval code using the code generation 
key associated with the credit card and this approval code is sent to the unique 
40 identification device (UID) of the cardholder using a communication network; 

the credit card issuer communicates the authorization decision to the 
merchant; 

the m&tcbaxxt generates an approval code based on the code generation key 
provided by the credit cardholder. 
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the merchant piompts the credit cardholder to supply the approval code that 
has been received from the credit card issuer via the cardholder's unique 
identification device (UID); 

the m^ichant compares the approval code it has gmerated with the approval 
5 code provided by the cardholder; 

the result of the conq^arison allows the merchant to make a decision regarding 
the legitimacy of the transaction. 

5. A communication component referred to as Unique Identification Device 
10 (UID) in the method of claims 1,4 is a device that is capable of receiving 

messages. 

6. A conmiunication component referred to as Unique Identification Device 
(UID) in the method of claims 1,4 is a device that is enable of receiving and 

IS sending messages. 

7. A communication component referred to as Unique Identification Device 
(UID) in the method of claims 5, 6 is a mobile phone. 

20 8. A communication component referred to as Unique Identification Device 

(UID) in the method of claims 5, 6 is an e-mail account 

9. A communication component referred to as Unique Identification Device 
(UID) in the method of claims S, 6 is a wireline phone (or Phone Number??). 

25 

10. A communication component referred to as Unique Identification Device 
(UID) in the method of claims S, 6 is a wireless phone . 

11. A communication component referred to as Unique Identification Device 
30 0^1^) the method of claims 5,6 is a pager device. 

12. A commimication component referred to as Unique Identification Device 
(UID) in the method of claims 5,6 is a personal computer. 

35 13. A communication component referred to as Unique Identification Device 

(UID) in the method of claims 5,6 is a personal digital assistant (pda) device. 

14. A communication component referred to as UID in the method of claim 3 is a 
device that is capable of generating appiowal code. 

40 

15. A conmiunication component referred to as UID in tiie method of claim 14 is 
a personal computer. 

16. A communication component referred to as UID in the method of claim 14 is 
45 a personal digital assistant (pda). 
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17. A communication component re&ired to as UID in Ibe method of claim 14 is 
a mobile phone. 

5 18. A communication component referred to as UID in the method of claim 14 is 

a pager device. 

19. A communication component referred to as UID in the method of claim 14 is 
an electronic organizer device. 

10 

20. A method as in claims 3 and 4 of generating an alphanmneric code using a 
Code Generation Key and an adjusted date/time stamp where the adjustment 
of date/time stanq>s is based on a time-zone agreed on as a point of resferrace 
by all systems involved in the processes of generating or comparing approval 

15 codes. 

21. A method as in claims 1, 2, 3, 4 of enabling the merchant, in a credit card 
transaction, to ascertain whether an individual credit card is protected by the 
method and system through reference to a *look up' server containing records 

20 of all types of credit cards protected by the method and system. 

22. The method of claims 1, 4 wherein the cardholder is informed, via their UID, 
of attempted fraudulent use of their credit card account by a third party. 

25 23. The method of claim 22 wherein the cardholder notifies theu: credit card 

issuer of attempted fraudulent use by replying to a message received ^ Ab their 
UID. 

24. The method of claim 23 where the reply mechanism is a return e-mail address 
30 on an email message containing the approval code generated by the credit 

card issuer. 

25. The method of claim 23 where the reply mechanism is an originating GSM 
number on a OSM SMS message containing the approval code generated by 

35 the credit card issuer. 

26. The method of claim 23 where the reply mechanism is a telephone number 
that connects to an automatic call directing service. 

40 27. The method of claim 24 where the reply mechanism is a website. 
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Figure l.a 
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Figure l.c 
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Figure 2.c 
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Figure 3. 
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Figure 6 
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